Atari Mega Archive 2/Atari Mega Archive CD - Volume 2.iso/8bit/sio2pc/sio2pc38.exe/README.TXT

Text File | 1994-02-13 | 98KB | 1,836 lines

SIO2PC: An Atari to PC

Interface System

by Nick Kennedy

    D I S C L A I M E R

I have tried to ensure that my software is free of harmful defects (bugs)
and of viruses.  However, either could slip through my defenses.  Use the
software at your own risk.  Similarly, I believe my hardware design to be
in accordance with good practice, and I have a number of satisfied users.
However, wiring errors, errors in my design, and configuration
differences are possible and I cannot guarantee that these problems will
not lead to damage to your equipment or software or other unforeseen
damages. Use at your own risk.  Furthermore, if you choose to construct
my interface yourself, you must be experienced with electronic building
techniques.  Even if you are experienced, you could burn or cut yourself
or experience other damage or injury, for which you must assume
responsibility.

I consider the SIO2PC system to be a service to the Atari user's
community. Although I accept shareware contributions, and do make a
charge for assembling interfaces or kits, I still consider my efforts to be a
hobby and a service.  IF YOU HAVE SENT ME ANY PAYMENT FOR
ANY SOFTWARE, KIT, OR ASSEMBLED INTERFACE AND DO
NOT WISH TO ASSUME FULL RESPONSIBILITY FOR USE OF
OR CONSTRUCTION OF THESE ITEMS, YOU MAY RETURN
THEM TO ME AND I WILL REFUND YOUR MONEY.  IF YOU
ARE CONSTRUCTING THE INTERFACE AND CANNOT VERIFY
THE ADEQUACY OF THE DESIGN ON YOUR OWN, SEEK THE
ADVICE OF ONE COMPETENT IN ELECTRONICS.  OTHERWISE,
DO NOT ATTEMPT TO BUILD AND USE THE INTERFACE.
DON'T USE THE SIO2PC ON COMPUTER SYSTEMS USED FOR
COMMERCIAL PURPOSES OR FOR CRITICAL APPLICATIONS.

INTRODUCTION    1
FEATURES:    2
HARDWARE REQUIREMENTS:    2
HISTORY:    3
SHAREWARE INFO:    3
READ ALL ABOUT IT:    3
TECHNICAL INFORMATION ON SIO2PC    4
REMOTE CONTROL PROGRAM:    5
FILE2PC PROGRAM:    5
STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:    6
USING RAMDISKS:    7
TIMING INFORMATION:    7
DOUBLE DENSITY:    9
FORMATS vs DISK SIZES:    9
FILE ACCESS: How it works & tips on efficiency    11
MORE DISK CONFIGURABILITY:    12
SIMULATED DISKS:    14
PRINT-THRU:    15
UNINSTALL DISK:    17
STATUS LINE INFO:    18
PC MEMORY USAGE:    19
DOS SHELL FEATURE:    19
VIRUS DETECTION:    19
REMOTE CONTROL PROGRAM USAGE    20
MAKADISK.EXE    21
FILE2PC USAGE INFORMATION    22
FUTURE PLANS, CURRENT PRICING    23
REVISION LOG:    25
PROBLEM DIAGNOSIS QUESTIONS    33
POSSIBLE PROBLEMS AND SOLUTIONS    33
USER'S QUESTIONS    36
WHO'S NICK KENNEDY?    39
OTHER PROGRAMS    39


INTRODUCTION

Greetings Atari and PC users! SIO2PC is now a "Shareware" product.  If
you know little or nothing about the system, let me give you a rundown.
A separate text file, SIOINSTR.TXT, gives more detailed information on
running the system and describes its features.

SIO2PC is a hardware interface and software utility package to allow
storage of your Atari files on your PC's hard and floppy disks, file
conversions in both directions, and Atari printer output redirection to your
PC's printer, screen, or file.

FEATURES:

Create 1 to 4 virtual Atari disks on your PC.

Virtual disks can be ramdisks or physical file access disks; disk
images can be up to 65525 sectors in size.

Save Ramdisks to PC hard or floppy disks.

Boot from the PC. Real drive not needed to start-up.

Create Single or Double density ram-drives.

No special Atari software patches. Use your favorite DOS.

Almost twice as fast as an Atari 810 drive.

Co-exists in the Atari daisy chain with "real" drives.

Software written in assembler: Compact and Fast.

Compatible all the way down to the hardware level - CIO, SIO,
even direct hardware calls to drives will work.

Print-Thru mode sends your Atari's printer bound output to your
PC's  Printer, Screen, or file.

File Conversion: Convert and transmit PC files to Atari, or Atari
files to PC files.

Won't endanger your PC's hard disk. Your Atari disk images are
stored as ordinary PC files. No direct sector writes used.

Status line shows you exactly what your Atari is telling your disk
drives: drive number, command, and sector number.

HARDWARE REQUIREMENTS:

SIO2PC connects any PC compatible computer to any of the Atari 8 bit
computers (400, 600, 800, 800XL 130XE).

The interface between your PC's serial port and your Atari's SIO port
requires a simple interface. It uses two IC's and a few capacitors and can
be built on a 2" X 3" prototype board. If you are handy with a soldering
iron, read the BUILD_IT.DOC file on your disk. It gives complete
instructions, including addresses of parts suppliers. If you wish, I'll build
one for you, or provide you a kit of all parts with drawings and detailed
instructions. See BUILD_IT.DOC.

HISTORY:

    SIO2PC has been over 3 years in the making. Before I got my PC,
I considered my alternatives for my trusty Atari 800. Should I invest in an
adapter and hard disk for the Atari? I realized that the huge PC market
made an entire PC with hard drive almost as cheap as adding a drive to
my Atari. So why not do both? The PC could store my Atari programs
(get rid of that huge pile of floppies), and I'd have a new computer to
boot! The project has worked out better than I could have imagined. The
PC is a great computer - in some areas. In areas where it is weak, the
Atari still shines. Curing the Atari's mass storage weakness makes it even
better.

SHAREWARE INFO:

    As you no doubt know, Shareware is a system which allows you
to receive freely distributed software, and pay for it if you find it useful. If
you build the interface and find that the system is useful, I request the
modest sum of $10 for the design and software. If you choose to buy the
kit or assembled interface from me, no additional payment for the
software is expected. Either way, registered users may upgrade to the
latest revision by sending a disk sized SASE and $5.00. Your suggestions
will be considered for future revisions. So far, I have always been able to
personally respond to questions and problem reports.

READ ALL ABOUT IT:

    Don't you hate to write off for a shareware program that looks
good in the ad, only to find an endless README file describing the
limitless complexities of the package? Now that I'm on the creating end of
that particular method of information overload, I can see how
documentation files just grow... But - SIO2PC is a simple menu driven
program which can, I believe, be mastered without instructions. So, skim
through the rest of this file and the other .DOC files for tidbits, and return
only if you have problems or specific questions after you get your system
going. Of course, if you decide to build it yourself, you will want to read
BUILD_IT.DOC carefully. Also, go ahead and run SIO2PC.COM and
play with the menu options a bit, even without the interface. It won't hurt
anything. Note: This DOC file gives some problem resolution
information, technical information, and more information on file transfer
features. For a more concise user's guide to the program, see the
SIOINSTR.DOC file.

    A NOTE ON A RELATED HARDWARE DEVELOPMENT

Recently, an SIO2PC user told me he was developing a hardware project
which would allow him to type on the PC and have the keystrokes
transmitted to the Atari via a PC parallel port and custom Atari interface.
The system also comminicated joystick positions, START, SELECT,
OPTION, and SYSTEM RESET button status to the Atari - AND
allowed turning the Atari on and off remotely, and turning the Atari's
cartridge on and off.  His idea was to tuck the Atari away, into a desk
drawer or something, and do everything from the PC's keyboard.  He
asked me to write to software for this project and integrate it into
SIO2PC, which I have done.  The hardware is more complicated than an
SIO2PC, having 8 or 10 chips and requiring internal installation in the
Atari.  If this sounds interesting to you, I'd be glad to send you the
schematic and a version of SIO2PC which includes the control functions
for this modification.  If you'd like to contact the designer of the interface,
he is Carl Mangaroni, 15764 Midwood Drive Suite 5, Granada Hills CA
91344  phone [phone].


TECHNICAL INFORMATION ON SIO2PC

SIO2PC is 100% written in PC assembly language. REMOTE.OBJ and
FILE2PC.OBJ are written in 6502 assembly language. MAKADISK.EXE
is written in 'C'.

SIO2PC recognizes the basic SIO bus commands: READ SECTOR,
WRITE SECTOR, PUT SECTOR, STATUS, FORMAT, FORMAT
1050 1.5 DENSITY.

Because it works at this elementary level, it should work with any DOS
and with non-DOS disk loader programs. You can also make boot disks
(without DOS) and boot them from the PC.

SIO2PC uses only MS-DOS calls to do file I/O on the PC. Because there
are no direct sector writes, etc., SIO2PC won't trash your PC disks. Just
use the right path/filename when doing writes.

SIO2PC uses file handles, so I assume it will require MSDOS or PCDOS
2.0 or later.

SIO2PC redirects the timer 0 interrupt for it's timing purposes. This is the
timer which supplies the BIOS its "timer tick", 18 times per second, 55
milliseconds per tick. SIO2PC also directly reads the timer as it is
counting down in a routine for more fine timing (the microsecond level).
If your PC doesn't use the standard timer chip (or compatible) with
standard port addresses, there could be problems. Note: Most PC Clones
are HIGHLY hardware compatible.

SIO2PC gets the port address for the specified COM port from bios data
area words at 040:0000, 040:0002, 040:0004, 040:0006 for COM  1,2,3,
and 4. I've found out that the POST routine typically doesn't set up the
addresses for ports 3 & 4. Therefore, version 1.01 will use default port
addresses 03F8, 02F8, 03E8, 02E8 for COM 1 - 4 if it finds a zero in the
BIOS data area word. If you know your port addresses to be other than
this, a third option is now available. Use your computer's documentation
to find the base address, and use SIO2PC's  "E" command to enter the
addresses directly.

REMOTE CONTROL PROGRAM:

The Atari serial bus reserves device ID's 31 - 38 hex for disk drives 1 thru
8. I have used ID #39h for the remote control function. When the
SIO2PC program finds this ID # in a command frame, along with a Write
Sector command, it expects to receive one sector (128 bytes) containing a
command string. It then acts on the string as
if it were a command tail from the DOS command line. Any error, or the
Atari EOL character, will terminate command processing and flush the
line of any further commands. It is best to end the string with a space as a
delimiter, especially if your command ends in a pathname, else your PC
may pause waiting for input or an ENTER keystroke. A REV 2.1 change
added this function to the REMOTE process: When DEVID = 039h and
DCOMND = 'R', the SIO2PC sends a 128 byte data frame to the Atari
containing the DISK status information string shown on the screen. The
string sent depends on the contents of DAUX1 which must contain 1 - 8
for disks 1 - 8. This function allows REMOTE.OBJ on the Atari to
update the user as to the status of the ramdisks, before and after the
execution of the remote function. In this way, the user can see if his
remote command went to error free completion. In some cases, the PC
may be busy carrying out the command when the data request is received.
For example a command to write a ramdisk out to a floppy disk may take
10 seconds or so. Therefore, REMOTE.OBJ tries 3 times, pausing 4.25
seconds between retries, before giving up on getting the information.

FILE2PC PROGRAM:

The FILE2PC program also uses its own bus ID as a trigger for the
FILE2PC program. ID# 03Ah puts the  program into File Transfer mode.
The Atari (running FILE2PC) always asks for Status of device 03Ah
before putting a sector. (Only Status and Write are recognized by device
03Ah.) If the first status byte (of 4) is normal (010h), then the PC is ok
for the transfer mode. If it is 0FFh, then the Atari will abort because the
PC has encountered an error. The process works like this: The Atari gets
Status, then, if OK, it sends a sector to the PC. The PC assumes that this
sector contains the pathname of the destination file, terminated in an
ATASCII EOL. The Atari pauses 4 seconds while the PC attempts to
create the file. (Note, any existing file of the specified pathname will be
overwritten.) After the Atari gets another good status, it starts sending
sectors of file information.

The AUX bytes, which usually carry  sector # information, communicate
the following to the PC:

AUX1 = 0:    Full sector, 128 bytes AUX1 = 1:    Last sector, AUX2
contains the byte count
AUX1 = 2:    Atari encountered an error, abort process.

As I said, the Atari asks the PC for Status after every write.


STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:

It's extremely simple. There is first a 16 byte header with the following
information:

WORD = special code* indicating this is an Atari disk file
WORD = size of this disk image, in paragraphs (size/16)
WORD = sector size. (128 or 256) bytes/sector
WORD = high part of size, in paragraphs (added by REV 3.00)
SPARES 8 (ten) unused (spare) header bytes (contain zeroes)

After the header comes the disk image. This is just a continuous string of
bytes, with the first 128 bytes being the contents of disk sector 1, the
second being sector 2, etc.

* The "code" is the 16 bit sum of the individual ASCII values of the string
of bytes: "NICKATARI". If you try to load a file without this first
WORD, you get a "THIS FILE IS NOT AN ATARI DISK FILE" error
message. Try it.

USING RAMDISKS:

SIO2PC uses, or can use, the PC's hard or floppy disks to store Atari disk
information. However, to give maximum speed, the disk information can
be buffered via a ramdisk set up in the PC's ram space. When the Atari
reads/writes its SIO2PC "disks", it is actually communicating with the
ramdisks in the PC's memory. The user can choose to load a ramdisk
image or save one back to physical disk at any time via menu selection.
For files too large to be installed as ramdisks, file access to the disk image
is used.

TIMING INFORMATION:

The Atari SIO2PC bus protocol specifies minimum and maximum times
between Atari commands and disk drive's responses. The minimums give
the Atari time to get ready to take the data from the bus if it has to do
some other work in the interim. The maximums let the Atari decide that
the peripheral isn't ever going to answer and it will give a "time out" error.
I have found that the system is very flexible and forgiving. I have used
wide variations and still had a workable system. But for one guy (you
know who you are, Joe!) or maybe two, I've made this menu to allow you
to experiment with different values. The system goes through this little
dance of command - acknowledge - data - acknowledge - complete, etc
with timings in between. In addition to these times inside the bus frame,
I've made a couple more (normally zero) time delays available.

First: On a serial bus, data is normally sent continuously, with no time
(except start and stop bits) between bytes. Now you can experiment by
adding some time here. (My system slowed down but still ran normally.)

Second: Some publications say that some UART (serial) chips can't stand
to be addressed as fast as some PC's are capable of addressing them. I
already had a bit of time delay in there, but now you can add some more.
The time delays work like this: Each unit is 850 nano-seconds which is
almost 1 micro-second. (Multiply units by .85 to get micro-sec.)
(Exception: the value for the printer delay is in 1/18ths of a second.) Also,
you must enter the units as a 4 digit hex number. Don't panic, it's easy.
Here are some conversions:

    DECIMAL        HEX

    0005            0005
    0010            000A
    0050            0032
    0100            0064
    0250            00FA
    0500            01F4
    0750            02EE
    1000            03E8
    2000            07D0

The timing menu gives default values you can use as a starting point. If
you want to see the menu updated with your choices, an item is available
from the menu (choose #8).
One problem with the TIMINGS menu is that it can't be addressed from
the command line tail, so if your system does need non- standard timings,
you have to set them up manually, each time you run the program. Not
any more, Joe! Here's a procedure to permanantly alter your program:

This procedure uses DOS's little utility "DEBUG," because everyone has
it. But you could use NORTON or similar if you want. I moved the
timing values to the front of the program and put an ASCII string in front
of it to make it easy to spot. Try this:

Get into the directory containing SIO2PC.COM. On the DOS command
line, type DEBUG SIO2PC.COM <ENTER>. Now you see a hyphen,
which is the DEBUG prompt. Now, type D <ENTER>. A table of hex
numbers appears. On the left is the corresponding SEGMENT:OFFSET
address for the first entry of each line. On the right is the corresponding
ASCII (text) representation of the hex bytes. You notice that my little flag,
"TIME DELAY VALUES: T1-T8, 2 BYTES PER ENTRY:" takes you
up to the line starting with offset :0130. That line contains the timing
values and looks like this:

????:0130 ?? ?? ?? 64 00 B0 04 2C-01 etc.
Here's the slightly tricky part: Each of those 2 digit hex numbers is a byte.
But each timing value is a WORD (2 bytes). And the PC stores words as
lower part first. So the values are: T1 = 0064, T2 = 04B0, T3 = 012C,
etc.

The good part is, you don't need to worry about all this junk, we're gonna
fix it in a very easy way. If you have been following me and are now in
DEBUG, get out of it by typing Q <ENTER>. Now, I recommend that
you copy SIO2PC.COM onto a floppy because it's a little scary using
DEBUG to write to one's hard disk. Ok, you've done that and you have
the floppy in drive A:. Get into A: by typing A: <ENTER>. Now, type
DEBUG SIO2PC.COM <ENTER>. Give the "GO" (run) command by
typing G <ENTER>. SIO2PC runs from the floppy. First give it a port
number, then go to the "A" menu and change the timings values to those
you have found to work on your system. Now, leave the timings menu
and QUIT SIO2PC. You will see by the hyphen that you are back in
DEBUG. Type W <ENTER> and the program will be written back to the
disk file. Quit DEBUG with Q <ENTER>. Now run SIO2PC without
DEBUG, and call up the timings menu again. You will see that the
DEFAULT column stayed the same but the CURRENT values are now
permanently altered. Hey, I didn't know that DEBUG could be so useful,
did you?  NOTE: You should get a message saying program changed,
possible virus.  Just choose to write a new CRC and the program will be
fixed.

DOUBLE DENSITY:
The Atari expects the first 3 sectors on a disk to be single density. This is
necessary if you are to be able to boot from the disk. SIO2PC uses this
format for its double density mode.

FORMATS vs DISK SIZES:

I generally haven't restricted these things, but recommend the following:
Use 143K size only for "enhanced" or "1.5" or "DOS 2.5" density. The
183K size was created for double density. A lot depends on your DOS.
Some DOS's can figure out the actual size of a disk, others may assume a
default. MYDOS is pretty smart. SPARTADOS probably is also. As of
REV 3.00, SIO2PC responds to "get" and "set" configuration commands,
and also allows you to select any size disk you want by specifying the
number of sectors.

As a result of changes made in REV 3.00 and beyond which allow
HUGE disk images, I now have additional information to present on disk
sizes:

File Access and BIG disks

The biggest change is the addition of file access to disk images.  Since this
type of access doesn't require setting up ramdisks, the disk image size isn't
limited by available ram.  You may choose the size of your disk images
using new size choice #5.  You specify the size in sectors.  If you're
interested in what this means in kilobytes, you can figure it from the fact
that a sector is 128 bytes for single density disks and 256 bytes for double
density.  Remember the status line field that shows 'W' if you've written to
a ramdisk but not saved it?  (And 'N' if the file has been saved.)  For
direct file access type disks, this field will contain an 'F'.

Note that you can force the system to use file access, even when there is
enough ram for a ramdisk.  You do this by following the filename by "/P"
for physical file access. Don't put a space between the filename and the
"/P".  The "P" will appear on your status line. (The "/" won't.)

Concerns about Speed

I was concerned that the overhead of using DOS and having physical disk
accesses might slow the system down.  On my two PCs, this hasn't been a
problem when using hard drives.  I use disk caches on both systems and
can't tell any difference between "ramdisk" and "file access" speed.  With
a floppy disk, my fears were justified.  Access was slow enough that the
Atari would time out and generate errors.  But, when I installed a disk
cache, floppy disk access worked fine too.  Some disk caches don't
support floppies.  Smartdrive (supplied with DOS 5 and WINDOWS)
doesn't.  I used one called LIGHTING.  It worked fine using conventional
memory while Smartdrive continued to run using extended memory.

Get/Set Configuration

Even after I first made some BIG disks, MYDOS 4.5 still couldn't figure
out that they were bigger than a standard 810 or 1050 disk.  The standard
Atari SIO protocol doesn't include a means for the drive to tell the Atari
what it is capable of (except in a very limited way).  I found that I had to
implement the extended SIO commands for Get and Set Configuration so
MYDOS would realize the actual size of the disk.  MYDOS does some of
this automatically (reads configuration on bootup).  But I found that I had
to explicitly do this in sequence so MYDOS would realize the disk size:

Create the new (blank) disk image.

Use the Set Configuration command, answering questions as
follows:  Configurable? Yes.  High Capacity? Yes.  Number of
Sector? xxxx.  Do this before formatting.

Format the new disk image.

Actually, SIO2PC doesn't do anything with the Set Configuration
command other than acknowledge it.  But it lets MYDOS know that the
disk is capable of more sectors than a standard disk.  The program WAS
going to also warn you if you tried to set the wrong density.  But it turns
out that MYDOS always tries to set high density when you answer "Yes"
to "High Capacity Drive?".  This doesn't cause a problem though: single
density still works OK.  I'm describing MYDOS because it's what I use.
YOUR Atari DOS may have its own quirks with regard to large drives.
MYDOS can become confused when you use the SIO2PC Swap Disk
I.D.s command.  MYDOS associates a certain disk number with a certain
configuration.  You may have to uninstall and reconfigure the drive with
MYDOS when you swap disks of different types.

Formatting

With regard to formatting, it can take a long time with a BIG disk image,
especially on a floppy.  SIO2PC sets a flag when you first create the disk,
to tell itself that the disk image is already blank.  So, when you format it,
the program doesn't bother clearing the disk.  This saves a lot of time.
After you write to the disk, the flag is cleared.  Then, formatting includes
clearing the entire disk image file.  This could cause the Atari to time out
and not realize the format was successful.  So you may want to avoid
formatting "used" disk images.  I can't think of a reason you'd want to.
(CREATING a new disk image can take a while too, but the Atari isn't
involved in this process, so it won't get impatient.)  I may improve the
program to speed up this process if it's a problem.  But creating new BIG
disks will probably be an infrequent operation for most of us.

*** NOTE: In a "rev 3.00 and 1/2" modification, I have taken a big step
toward curing the slow formatting problem.  Instead of writing blank
sectors one at a time, I now write zeroes in blocks of 4K at a time,
dividing the number of DOS calls by 32.  This only works if there is at
least 4K of free ram. Otherwise, formatting will still work slowly, as
described above.

Note that you need to be a bit more careful when formatting file access
disks.  With ramdisks, you could always choose to not save the formatted
disk image, so your original was safe.  With file access, formatting
actually clears your disk image file.

Another addition with this revision is that you can now number your disks
as 1 - 8 instead of 1 - 4.

Incidentally, you may wonder why your old 92K and 143K disks are now
90K and 140K.  This has to do with the difference between a kilobyte as
1000 bytes and a kilobyte as 1024 (2^10) bytes.  Revision 3.00 divides
the disk size in bytes by 1024 to establish the disk size.

FILE ACCESS: How it works & tips on efficiency

It's pretty simple.  MS-DOS maintains a pointer into open files which can
be set by the program. SIO2PC maintains a corresponding pointer to the
next Atari sector. When SIO2PC receives a read or write sector request
from the Atari, it calculates the file offset from the sector number.  It
compares this to its record of where the pointer is now. If they differ, it
asks DOS to point to the new location.  Then it asks DOS to read or write
128 (or 256) bytes and increments its internal sector pointer by one, since
DOS's pointer will now be at the next 128 or 256 block of the file.  As
you can see, if the Atari asks for sectors sequentially the pointer
automatically moves along in step and no separate requests to reposition
the pointer are needed.  This is a good reason to try to keep your disk
images unfragmented.  Actually, it's possible to have things DOUBLY
fragmented: fragmented Atari disk images and fragmented PC disks.  To
avoid Atari fragmenting, you should first put files on the disk which you
won't be deleting or changing: DOS, games, application programs.  Last,
put on any stuff that will change: data files, text files, etc.  If you suspect
your disk is fragmented it's easy to undo.  Just do a file copy (*.*) from
the fragmented disk image to a newly created and formatted blank disk
image.

MORE DISK CONFIGURABILITY:

I've heard lots of reports about the inability to format certain disk image
sizes.  My adding the "get configuration" and "send configuration"
functions in Rev 3.00 in some cases seemed to make matters worse.

I'm now getting into an area where the specific DOS one uses makes a
difference.  So my treasured concept of "DOS independence" of SIO2PC
is going out the window.  The problem is this:  How can the system tell
the Atari exactly what size and type of disk it is emulating?  The 12 byte
configuration table exchanged via the GET/SEND CONFIGURATION
commands would seem to be the answer.  Unfortunately, both MYDOS
and SPARTADOS admit to ignoring most of the information exchanged.
The variables are:

SINGLE/DOUBLE DENSITY: 128 or 256 bytes/sector
SINGLE/DOUBLE SIDED DISK
NUMBER OF TRACKS/SIDE: TYP: 35, 40, 77, 80 expected
NUMBER OF SECTORS/TRACK: TYP: 18 or 26 expected


The MYDOS doc indicates that it likes to consider the disk to be one
huge track containing all the sectors.  This seems to work pretty well for
SIO2PC.

SPARTADOS evidently expects to receive information which matches its
expectations about certain combinations.  The sizes under the choice
6/Other are intended to give SPARTADOS what it expects.  (As
standards, they are probably good for other DOSes too.)

One thing I've recently learned (I think it's true, anyway) is that
SPARTADOS consideres 26 sectors/track to be "1050 enhanced density"
in all cases except for 77 track drives which always have 26 sectors/track.

The bottom line is this:  Even though you can choose a disk image of any
size with the new SIO2PC option #5, you may have to adhere to certain
standard sizes when using SPARTADOS.  I've added a lookup table to
the program.  If the disk size matches a  certain standard, it reports a
combination of standard values to the Atari.  Otherwise, it uses the
MYDOS technique of 1 track holding all sectors.  Note that this routine
puts a tilde ( ~ ) in the ERR field of the status line if it finds a standard
size.

Note that when you choose double density, the basic 1, 2, 3, & 4 choices
won't be seen as a standard size, but the equivalent chosen from sub
option 6/More WILL, for technical reasons too boring to go into here.  As
I've said, this usually doesn't matter, because most DOSses don't use the
GET/SEND configuration capabilities anyway.

You could compute some standard sizes like this:

Number of Sectors = (#TRACKS * #SIDES * # SECTORS/TRACK)

Size in Bytes = (Number of Sectors) * (#Bytes/Sector)

(For the Size in Bytes, subtract 384 for double density, because the first 3
sectors are always 128 bytes.)


All YOU have to pay attention to is the density and the number of sectors.
SIO2PC will report the other numbers to the Atari. For MYDOS, just
randomly picking a number of sectors, without regard to standard sizes,
seems to work fine.

As I said before, the addition of the GET and SEND
CONFIGURATION info commands in some cases did more harm than
good.  For this reason, I've added yet another feature.  Now you can turn
on or off the configuration transfer function.  Since the main menu was
getting full, I added this to the TIMINGS menu.  Just hit 'A' to see the
timings menu.  Then hit 'C'.  The status of the installed disks will be
shown.  'Y' means they DO respond to configuration commands.  Enter
the disk's number to toggle its status with regard to this function.  I believe
this should only be necessary when getting ready to format, if at all.

I realize this discussion of REV 3.01 isn't exactly simple.  I hope you can
glean the necessary info from it.  It should be worth the effort to get
ULTRA SPEED going and to cure formatting problems.  Call or write if
you have problems, bugs, or suggestions.  I'd especially like any
SPARTADOS experts to tell me how it tells me to go back to high speed.

What is the '@' command SPARTA sends to device $4F?  Also any info
on how to get SPARTADOS to accept ANY size disk image would be
useful.

Rev. 3.05:

I added many more choices to the standard disk sizes for the "create disk"
option (option #6).  The new choices are those which correspond the
selections in the SPARTADOS format menu.  This is to make your
choices easier when using SPARTADOS. Internally, things still work the
same.  Again, with MYDOS, you shouldn't need to worry about certain
prescribed sizes.  Rev. 3.17 refined and corrected much of this.

SIMULATED DISKS:

The main event for 3.05 is the addition of what I call "simulated" disks.
This allows you to install any PC file as an Atari disk, without the
necessity of converting it to an Atari disk image..  This is more or less
intended to replace the much despised MAKADISK.EXE.  The features,
theory of operation, and limitations are described below:

The simulated disk is always single density (no size limit) and DOS
2.0/2.5/MYDOS compatible.  It can't be written to, and can only be read
sequentially (no random access).  You CAN copy your executable files to
the PC with FILE2PC and load (run) them directly using this new
function.  If you ask for a directory, you will see the PC file's filename on
your Atari. (The length in sectors has no meaning.) Normally, after the
end of file has been reached, the system automatically unloads the disk.  If
you don't want this, use the /N (no space) option after the filename and
the file pointer will be reset to the start of the file after the end is reached -
making the file available to read again.  A new command has been added
to install the simulated disk - the "I" command.  It replaces the old "Z"
command (create double) which is now a separate choice under the
Create Disk option.

The new function works like this:  A simulated directory sector is given on
demand (#361). (When read, it causes the file pointer to be reset to the
start of the file.)  There is also a simulated sector #1 and sector #360
because some DOSes read these sectors to get information about the disk.
The simulated directory supplies a dummy sector pointer to sector 401 to
start the file. Each simulated data sector increments the sector number for
the "next sector" link.  Thats why the status line will show you reading
sector 401 thru 700. Then, it rolls down to number 401 again.  So if it
rolls over, you have read 300 (As of 3.10, trying to write doesn't return an
error to the Atari, it "pretends" to write the  sector.) Trying to read a
sector out of sequence doesn't return an error either.  The program
woould still just supply the next 125 file bytes if this happened.  Note: if
you need full functionality (READ, WRITE, RANDOM ACCESS) for
your Atari-file-on-a-PC, just copy it to an Atari (SIO2PC) disk image.

There are a lot of uses for this new feature.  You can download Atari files
to your PC and immediately load/run them on the Atari.  You could
program in 6502 on the PC using a cross assembler and load the files to
the Atari with no translation required. You may choose to keep some
favorite programs available under a "one Atari file per PC file" basis as an
alternative to having files under Atari disk images.

With rev. 3.11, boot files may also be simulated.  To use this feature, just
put /B after the file name.  You can combine /B and /N if you want.  The
program will send the next sequential 128 bytes to the Atari each time it
requests a sector, until the end of file is reached.


PRINT-THRU:

The serial bus ID for the Atari printer is 040h. With PRINT-THRU in
effect, the program answers bus commands directed to the printer and
routes the data to the PC's printer or screen, as selected. Note that the
Atari uses an EOL character (09B hex) to mark the end of line, while the
PC uses carriage return and line feed (CR/LF) characters. So SIO2PC
gives you the option of making the translation. If you are printing text,
you should translate. For graphics, probably don't translate. You can also
strip the high bit if you want. The reason?  ASCII is a 7 bit text code.
Computers use 8 bit data. So, text with the high bit set is not defined
under ASCII, and different computers use it differently. On the Atari, text
with the high bit set is printed to the screen as inverse video. On the PC
you may get graphics characters. So, when printing text, you usually want
to clear the high bit. If you are printing 8 bit graphics data, you usually
don't want to
change it.

For revision 2.6, I've made some changes to the PRINT_THRU function.
The reasons, and other comments, are summarized below:

PRINTER NOTES, REV. 2.6

Due to reports of problems with the PRINT-THRU mode in certain
cases, I've reworked the print-thru routine.

My basis for this feature is to try to provide 100% compatibility with the
Atari 850 Printer/Serial interface, since it should be the standard for the
Atari. I went back and reread the functional description in my 850
manual. Here is a summary:

The Atari printer handler (in the computer's CIO, not in the 850) sends
fixed length records (40 characters) to the printer. If an EOL (RETURN
key) is encountered, it fills the rest of the buffer with spaces and sends it.
Note that software on the Atari doesn't necessarily have to use CIO. It can
send data directly to the serial port using SIO. Fixed length, 40 byte,
records are still necessary because the interface expects them. Now, when
the 850 receives a 40 byte record from the computer, it goes by these
rules:

1) Send all bytes to the printer, as 8 bit data (no clearing the high bit)
except,

2) If an EOL (9B hex) is encountered, convert it to a CR character, and
ignore the rest of the buffer (assumed to be extraneous spaces supplied by
CIO) except,

3) If several consecutive EOLs are found, translate them all to alternating
CRs and spaces and send to the printer. NOTE: rev 2.8 took out the
spaces. My version was adding a space even if there was only one EOL,
causing alignment problems in the printout.

My interface was designed to provide several modes of operation, one of
which would emulate the 850 exactly. However, it wasn't doing some of
the things above. It didn't ignore characters after the EOL. It didn't
translate multiple EOLs to multiple CRs, only the first. It also translated
EOLs only to CR plus LF, not CR only. Now you have the option of
doing either.

What do the 850 rules above mean to the Atari printer programmer?
Well, as I see it, you can NEVER send a hex 9B to the printer, because
the conversion is irrevocably hard coded into the 850's ROM. Since
graphics data by nature can represent any dot pattern, it must include all
possible combination of bits, including $9B. This really isn't a huge
problem. The software would just have to detect EOLs and change one
bit. One dot's worth of error out of every 256 * 8, on average, won't hurt
anything. Another "cure" would be to have a printer which requires 7, not
8, bit data. Since $9B has its high bit set, it would never be required to
send graphics data. (Just as it is not required to send standard ASCII text,
a 7 bit system.)

All this info is presented for your amusement only. Hopefully, if my
emulation of the 850 is correct, your software will play just like it did on
your Atari printer. Of course, the Atari software will have to be
configured for the characteristics of your PCs printer, not your Atari's
printer, assuming they are different.
Rev 2.10 information: I added a value to the TIMINGS menu for the
printer. This is experimental at this time. One guy has a problem with the
system (PC) locking up after 3/4 page or so. I think maybe his printer isn't
handshaking properly, so I've added this timing value, to keep from
"overrunning" his printer. The normal value is 0. If you have problems,
add a little time. This value is in units of 1/18th of a second, so keep your
number small or you'll be in for a long wait. It is the value used between
sending of 40 byte records to the printer. Figure out about how long it
takes your printer to print a line and use about half this value in seconds.
So if your printer printed a line in 1 second, the value used would be
0009 for 9/18 of a second.

In 3.07, I added another translation to the PRINT-THRU function.  Now,
you can also change the ATASCII tab character to a standard ASCII TAB
in the PRINT-THRU process.  A 'T' on the PRINT-THRU status line
shows that you have chosen this option.

UNINSTALL DISK:

Why is it important to be able to do this?  Well, if you have already used
up all your memory in defined ramdisks, you can't overlay them with new
ones unless you remove the existing ones. This often would mean you had
to quit SIO2PC and restart it to get the configuration you wanted. Now,
you can delete ramdisks, and thanks to "garbage collection" performed by
the program, all data moves down to fill in the hole. So, you now have
free memory equal to the size of the deleted disk.  Uninstalling "file
access" disks doesn't free any ram, but it does free up one of your four
allowed virtual disks.

STATUS LINE INFO:

I've  created  a special status line, which is displayed  at  the bottom of the
screen, to help identify problems and to show  that the SIO2PC program
is actively doing something. It shows:

LOC: An identifier for the subroutine being executed.

CMND: SIO command from the Atari (Read, Write, etc.)

LAST: Command received previous to the one above.

DEV: Hex number for device being addressed by Atari. Note
31 - 38 = D1 - D8; 40 = Printer, 39 = Remote Control program
3A = FILE2PC program.

COM: High/Low status of the Atari command line.

ERR: An error code returned by one of SIO2PC's routines.
A character here doesn't necessarily mean a problem.  To aid
me in debugging.

SEC#: The sector # currently being written to or read from     by the
Atari.

RAM: The amount of RAM you have free for use.  It changes as
you install and uninstall ramdisks.

SPEED: N means normal speed 19.2K Baud, H means high speed,
as in Sparta Dos' high speed I/O.

Note that the status line is updated even when the device being accessed
isn't an SIO2PC device.  This allows you to use SIO2PC to eavesdrop on
the SIO bus.

PC MEMORY USAGE:

The technically inclined may want to know how the program decides it
has the right to RAM for its ramdisks.  Well, I initially wrestled with this
one. I was trying to use a DOS function for "Allocate Memory," but I got
an error code meaning "no memory available."  This was crazy, because
SIO2PC is a very compact program. It turns out that when DOS runs a
COM file, it allocates ALL available memory to the program. This is
because DOS is intended to be a single tasking system.  I took advantage
of that fact. My program doesn't ask for memory, it just takes it, as
though it's the only player (which it should be). (Note: TSRs loaded
BEFORE SIO2PC are safe. SIO2PC only uses memory higher than that
allocated to itself.)  I use an internal DOS variable to decide if there is
enough memory to load/create the ramdisk you request.

DOS SHELL FEATURE:

The main improvement added in rev. 3.08 is the ability to "shell out" to
DOS. What this means is, you return to the DOS command line prompt
"C:>" while SIO2PC is still resident.  Then you can run DOS commands
or programs, type EXIT, and be back in SIO2PC. You will of course be
subject to limitations on the amount of memory available with SIO2PC
and any ramdisks you have resident in memory. It's a good idea to avoid
messing with (deleting, renaming) any files that SIO2PC has open, such
as file access disks.  (SIO2PC doesn't leave files open when ramdisks are
loaded.)  In order to make this function fit on the menu, I had to dump a
function.  So, I took "R" off the screen. This is the function which
restores the screen (ESCAPE also works).  Note that "R" still works, you
just don't see it on the menu.  Due to the way memory is managed, you
shouldn't install any TSRs while in the DOS shell.

VIRUS DETECTION:

I got a rude introduction to the world of viruses a while back when I
found that my system had been attacked by a virus.  Since then, I've
added the byte count on the sign off message as a small first step. Rev.
3.03 adds some more complex checks.  As soon as SIO2PC gets control,
it loads a second copy of itself into memory. Why?  Because the virus
may have already "done its thing" to the running copy, then fixed it to
look unchanged.  Anyway, SIO2PC loads a second copy, and checks to
make sure it isn't any bigger than its supposed to be. You get a message if
the size is wrong.  It then does a CRC calculation on the copy. If the CRC
result isn't as expected, you get another warning.  The program will still
run, however.

I translated the CRC calculation algorithm from C code in a book on
serial communications.  My version may not be exactly right, but it does
work.  I've tried toggling a single bit and got the warning.  Please note that
no system is foolproof.  Virus and counter-virus development is like the
arms race.

These additions don't seem to slow down program loading to any
appreciable extent, but for those of you who can't tolerate ANY
slowdown, I've included an override.  Just put /v or /V on your command
line somewhere after the program name and the virus checking will be
skipped.  (You should put the /v after the port # since the program comes
up expecting a port #.)

If you make changes to the program by interrupting it while it's running
(as I showed you how to do elsewhere), it may make the CRC wrong.  To
fix this, I've had the program print out the  calculated CRC with its sign
off message. The idea was that you could patch in the correct CRC value
with DEBUG.  However, with rev 3.08, that's been automated:

In 3.08, I changed the virus detection function (CRC check) so that the
program will offer to fix SIO2PC's internal CRC value to that just
calculated.  This is mainly for me, so newly assembled versions can have
their CRC set automatically.  If you get the warning and haven't changed
the program, better get out your virus checker and go over your files.
Delete SIO2PC and install a healthy copy.

REMOTE CONTROL PROGRAM USAGE

This section is to tell you how to use the Atari program called
REMOTE.OBJ. This program is found on your disk image file,
ATARI.ATR.

The program allows you to send commands to SIO2PC from the Atari,
just as if you were typing them on the PC's keyboard. So, if your Atari
and PC are in different rooms (or something), you can swap ramdisks,
save and load, etc. without leaving the Atari. The file is fairly small, and if
you plan to make use of it, you should copy it to as many ramdisk images
as necessary to assure that it's accessible when you need it.

When the program comes up, it shows a list of most of the SIO2PC
commands. If you want to study this list, hold down the START key, or
else it will scroll off after 3 seconds. The program next gets the status's of
the 4 disks from the PC and puts them on the screen. Now you are ready
to enter your command. Say you want to load a disk image from
A:\ATARI.ATR into ramdisk #4. Just type L4A:\ATARI.ATR and
RETURN. Note that some commands give you prompts which you must
answer in your command string, so anticipate them. For instance, if you
tell the PC to write back a file, you need to anticipate "USE EXISTING
FILESPEC?" and "FILE EXISTS, OK TO OVERWRITE?". Note that if
writing was successful, the "W" in the status line will have changed to "N"
after completion. One person was using REMOTE.OBJ on the Atari as
an AUTORUN.SYS, and feeding it with a batch script from
SPARTADOS to automate setup of his MIO ramdisks. Because he
couldn't simulate a character from the keyboard with SPARTADOS, my
"Run another command (Y/N)" left him stranded. For this reason, you
can now skip the command by starting your string with a space. When
REMOTE.OBJ sees the space, it will send the command to the PC, then
return to DOS automatically.

Note: After transmitting a command, REMOTE.OBJ is allowing the PC a
certain number of seconds to complete it before giving up on getting the
ramdisk status. If you find that not enough time has been allowed, let me
know so I can add some more. (If you choose to skip the rerun prompt,
you won't be getting the ramdisk status after command completion.)

MAKADISK.EXE

As I stated earlier, the need for MAKADISK.EXE has been pretty much
eliminated by the introduction of SIMULATED DISKS, which allow the
Atari to load in a file which is in native PC DOS file format.  However,
you may still find a reason to use MAKADISK.

The purpose of this program is to allow you to take a PC file and convert
it into an Atari ramdisk image so your Atari can read it. For instance, you
may have a modem on your PC only, and want to download Atari files.
Or, you may want to write program source code on your PC, because it
has an 80 column screen, and send it to the Atari for compiling.

At present, this program is basic - it allows you to put only one file to a
standard single density ramdisk image. You should then boot the Atari up
with SIO2PC and copy the file to a real disk or a "full featured" disk
image (one created by SIO2PC and your Atari DOS). Then you may as
well delete the MAKADISK created ramdisk image, it has served its
purpose. You can't write more files to it, the VTOC isn't correct.

Note that another utility may be useful. I want to make one, but they are
available in public domain (PC Magazine's utilities disk has one). The
utility needed is to translate PC "end of line" codes (CR and LF) to the
Atari EOL code, which is hex 9B. If you are translating text files, you will
probably need this. Binary files (such as executable programs) shouldn't
generally be translated.
Note that MAKADISK asks for three things:

1. The name (or pathname) of the PC file to be converted to Atari.

2. The name of the PC's ramdisk image file. This is the name you will
give SIO2PC when you load the ramdisk image. I use an .ATR extension
for all my ramdisk images stored on the PC, but you can use what you
want. Note, MAKADISK doesn't tell you if there's already a file by that
name, so be careful, existing files will be overwritten.

3. The name of the Atari version of the file. This is the name you will see
in the first position on your Atari screen when you ask DOS for a
directory.


FILE2PC USAGE INFORMATION


FILE2PC.OBJ is an Atari program found on your ATARI.ATR disk
image file located on the distribution diskette. If you run this program on
your Atari, it will cause SIO2PC to go into the file transfer mode. Just
follow the prompts on the Atari. You can read the technical details in the
TECHNICAL INFORMATION section if you're interested. This file
transfer function has been much requested. A lot of people seem to have
text files on their Atari's and want to transfer them to their PC's so they
can pick them up on the PC's word processor. I should tell you that the
usual warnings apply to this: Different word processors use different
formatting control codes. This is true even if you aren't going to a
different computer. Plus, the Atari has its own method of ending a line. It
uses an EOL (9B hex or 155 decimal) to tell its editor to drop the cursor
down one and move to the left margin. The PC, on the other hand, uses
two codes, CR & LF or carriage return and line feed. They are hex codes
0D and 0A (decimal 13 and 10). There are utilities available which
translate codes like these. There was one called CHANGE on PC
Magazine's utilities disk. Unfortunately, it only works with files up to 40K
in size. I want to write one without this limit. A common denominator is
the so called ASCII file, which is free of specific non-standard formatting
commands. (Like this file.) If your Atari word processor will output a
plain ASCII file, you may want to use the option before sending it to the
PC. Some Atari programs will allow you to use an OS feature which lets
you PRINT to a disk file. This should yield a plain ASCII file. Also, if
you wanted to send it to your PC's printer, it should definitely be ready to
go in this format. Anyway, you will probably want to use a filter program
to change your 9Bh's to CR/LF's as a minimum. Note that 9Bh looks like
a "cents" symbol on my PC. To see it, hold down ALT on the PC and
type 155 on your numeric keypad.

Rev 2.3 note:  Now that the PRINT_THRU function allows you to
"print" to a PC file, you have another method of transferring your Atari
text files to PC files. And since the PRINT_THRU option has EOL to
CR/LF and TAB conversion capabilities, it may be easier to use in some
cases than FILE2PC. Remember, Atari DOS allows you to COPY a file
to P:.

FUTURE PLANS, CURRENT PRICING

I now feel that SIO2PC is becoming a pretty mature program. However,
there seems to be no limit to the number of enhancements one can dream
up. I would like to take a stab at making the system capable of copying
copy protected disks, with the ability to run them from SIO2PC storage
without the original disks. I don't really see SIO2PC as some sort of copy
protection cracker, but it is a pain for users to have this system and still
have to rely on an Atari drive to run some of their software. I'm not sure
how effective this system will be, because I'm not up on all copy
protection techniques, but ... we'll see.

I also hope to soon try to implement the Lightspeed I/O feature you
Spartados/U.S. doubler users know and love.  DONE

It also occurs to me that some sort of Auto-compaction should be
possible.  I could have the program keep track of the highest sector #
written, and store only data to that point.  The empty portions of partially
written disks, in general, wouldn't take up any disk space.  (DOSes
generally use sectors sequentially, from low to high numbers.)


On the hardware side, I am still trying to simplify the assembly of the
interface. It takes far too much time for the price charged to wire one up.
So, I may soon make the DB-9 connector mount on the board and
protrude thru the case, just like the ones on your PC do. This will save a
lot of time stripping cables and wiring/assembling connectors. It will also
mean that the interface will need a DB9S to DB9P or DB25S to DB9P
cable to interconnect it to the PC.  I'll probably soon change the hardware
so that the interface won't interfere with the SIO bus, even when the PC is
turn off or not connected.

Please see BUILD_IT.DOC for the current prices. I had hoped (and still
do) to hold the price as low as possible. Shortly after  receiving mention in
Antic, I discovered a hardware problem which made it necessary to
double the complexity and cost of the interface. SIO2PC is still just a
hobby to me. I don't hope to recover my programming time (about 3
years). But I seriously underestimated the time needed to assemble the
interface, and do hope to get some reward for that time. (Since soldering
isn't fun*, like programming.) Since I've sold only a few interfaces so far
(about 50 as of Jan, 1992), I haven't had a custom circuit board built.
Therefore, I have to hand wire the circuit on prototype boards, with quite
a few jumpers required.  What's the bottom line of all this whining? I
expect to have to either streamline assembly, raise my price, or both. I've
also considered making the software "shareware" and publishing the
schematic so users could pay me for the software and build their own
interface from scratch or optionally order from me. Any advice?    ***
DONE!!!


*Building one is fun. Building 10 or 20 is drudgery.


REVISION LOG:

1.00:  First release

1.01:  Now uses default addresses for COM 3 & 4 if BIOS data doesn't
give addresses. Added option menu item "O", sub option "I" to allow
ignoring CTS, "I" is now the default. If your status line will show "H" in
the Atari field with the Atari "on", you can toggle this function. I believe
the program functions fine while ignoring CTS, however, and may
eventually delete the input entirely.

1.02:  Changed the stack pointer to be 256 bytes at the program end. This
means the program now only uses about 8K instead of a full 64K
segment. Now, on my system with only DOS and a 10K Mouse driver
installed, I can get 3 - 143K ramdisks (as usual) plus an extra 92K
ramdisk. Killed a bug which caused the program to not recognize SIO bus
command 022h, which is "format in DOS 2.5  1.5 density". Added clear
of all disk info lines every update when I noticed that garbage sometimes
remained from old filenames. This change is cosmetic only. Reduced the
timeout value which the disk returns to SIO. This should reduce the time
the atari waits when it is given an invalid format command. Changed the
method used to put command codes to the status line. Now even invalid
command codes will get listed, adding to ease of de-bugging. Got rid of a
bug which could cause an invalid error report when writing a ramdisk
back to an existing filename. Changed the method used to control the
RTS line. Now the other lines of the MCR aren't affected. Note: These
errors are primarily the result of switching from one assembler to another.
(now on QUICK ASSEMBLER).

1.03  4/3/90 Rewrote the routine for generating time delays. I had been
reading the refresh timer. Now, I'm reading the system timer and using a
different method which should be more reliable and compatible.

1.0  4/10/90 Added option "E" under Options. Now, the user can
manually input port addresses.  The program also now puts to the screen
the actual address used, whether manual or automatic.  Put the address in
Hex format.  The standard addresses for COM 1, 2, 3, & 4 are: 03F8,
02F8, 03E8, & 02E8.

1.05  Added some diagnostics. Now, on initialization of a PORT, the
software reads back register LCR and gives a warning message if doesn't
read as programmed. Then, the port is tested by sending a byte in the
loopback mode. A warning is given if it fails. If these warnings occur,
your program will probably fail. Either you have an incompatible COM
PORT, or the program is using the wrong PORT addresses. Check your
documentation and use "E", described above to set the PORT addresses.
Also, the program now always sets up the UART chip (serial port chip)
directly, instead of using BIOS. Also in this rev, the timer chip, timer #0,
is now programmed in mode 2, count = 0 for a period of 55 milliseconds.
This is the way it should already be, but now I'll take no chances. I
replaced my "long time" timer routine, the one I use for keeping warning
messages on the screen for 2 to 3 seconds. The old routine would
occasionally lock up, or take far too long. Now, I have redirected the
timer 0 interrupt for this purpose. Rev. 1.05 fixes a small bug which could
result in extra characters on the filename line. It also fixes a bigger bug -
the program used to write to a random address (Segment Register wasn't
initialized) when it thought it was putting the default port address into the
BIOS data area, after it had been found to contain 0. Now it just leaves
the 0 alone.

1.06  Quite a few changes. Added the FILE2PC subroutine, which works
with the FILE2PC.OBJ Atari program. This gives you the capability     of
sending Atari files to the PC to become PC files, rather than Atari disk
images. This means you can read the files with your PC's word processor.
Rev. 1.06 also changed the logic on switching the PC's data out line to tri-
state (off line) level when it is not in use. Some people were having
trouble with erratic and slow operation, and the switching of this line was
believed to be causing spurious pulses. Now it only turns off when a non-
SIO2PC device is addressed, less that 1% as often as before. Another
addition to rev 1.06 is the addition of double density.     Now you can
choose 183K ramdisks and double density sectors. Note that sectors 1,2,
& 3 are single density, so the ramdisk can be a bootable disk. Currently,
you can only specify a double density ramdisk by choosing "Z" instead of
"C" for the "Create Ramdisk" function. Then use a DOS that recognizes
double density, such as MYDOS. I also made some changes to the
LOOPBACK test performed on the UART (serial chip) upon
initialization. I found I was getting occasional "failed loopback test"
messages when everything was really OK. I did some fine tuning and
haven't gotten a bogus message recently.  I also added a function ("R"),
which allows you to restore a trashed screen. Despite my best efforts,
DOS will sometimes manage to sneak in one of its messages, causing a
scroll and messing up the screen. Use this feature to fix it. (As of rev 2.8,
ESCAPE does the same thing.)

1.07  I added a directory display function, under Options. You can just
give it a filename, including wildcards to search the current directory, or a
complete pathname to search other directories. Now, when you're in
SIO2PC and can't remember the filenames of your disk images, you don't
have to quit the program to find them. I name all my Atari disk images
with the     extension ".ATR" and so I search for "*.ATR". Also in this
release, when you choose "Quit", the program warns you if you have
written to any ramdisks but not yet saved them back to disk.

    Rev. 1.07 was to include the "PRINT THRU" option, but it's not
    quite done. Rev. 1.08 will have it soon.

1.08  PRINT-THRU mode incorporated. Now, you PC can serve as an
Atari to printer interface. You can have your Atari's printer output go to
either the PC's printer or screen. You can also choose  whether to convert
EOL's to CR/LF. Also in this rev, I added an Author credits screen. This
screen goes away as soon as you give the port #. I moved the "Restore
Screen" function from the Options menu to the Main menu. After having
Atari output printed to your screen just press 'R' to restore the menu.

1.09  Added feature to allow choice of stripping high bit on PRINT-
THRU data. This way, Atari inverse video text will come out as normal
text. (Without, it would print as garbage.)

2.0  Added function to allow deletion of a ramdisk. This function fills    in
the hole created in memory by the deletion  and allows the freed memory
to be used in creating other ramdisks.

2.1  Changed the Atari program REMOTE.OBJ and changed SIO2PC to
correspond. REMOTE.OBJ now asks for ramdisk info from SIO2PC at
program start and after each command. SIO2PC sends that info to the
Atari. Now, the remote user can get a fair idea of whether his command
was successful or not. Also, now a leading space in the command string
will cause REMOTE.OBJ to go back to DOS after completion of the
command without asking if the user wants to send another command
string.

2.2  Changed the point at which the program looks at the device number
in the command frame and disables the data out line if a non-SIO2PC
device is being addressed. This is in hopes of     curing an interference
problem some users have experienced when using real drives and SIO2PC
together. 08/05/90

2.3    AARGH!!  Rev. 2.2 still didn't take care of the elusive "problem".
So, this version adds a switch which allows the user to lock SIO2PC's
data out line into the "enabled" state. This was  verified earlier to work.
Also, I finally did away with the old CTS or "Atari" line, which didn't
seem to have any advantage. The idea was to carry the 12 volt line from
the Atari to the PC to tell the PC it was on. It turned out that some PC's
didn't recognize it, or some Atari's didn't have the 12 volts out. But,
anyway the program worked fine without it. Another big change is the
redesign of the user interface screen. It has become obvious to me that the
separate "Options" screen was cumbersome and unnecessary. So I've
combined all choices onto one screen. This means there are some
functional changes, for those of you using batch and remote script files.
First, option "O" is no more. Also, the "D" display status line choice is
now "T", toggle status line. Another enhancement added with this
revision: Now, you have a  third option with PRINT_THRU: You can
specify that the Atari's printer bound output be sent to a PC file.

Still another change is to the Status Line. Replacing the "Atari" line status
is the DEVID identifier. This is the SIO bus ID of the device being
addressed. Elsewhere in this README file are the ID's of various bus
devices. Also, as of this revision, the program updates the Command and
DEVID fields even when a non-SIO2PC device is being addressed. Now
you can see what your Atari is telling other devices, if it's trying to address
non existent devices, etc.

2.4  Changed the directory print-out from 2 to 4 entries per line.  Now
your directory can have more than 90 entries without scrolling off the
screen. Wrote handlers for the Critical Error Vector and the Control - C
vector. The Critical handler is the one which gives you the Abort, Retry,
Fail message if your drive door is open, the printer is out of paper, etc. It
turned out that this would let you bail out of the program without going
through my normal "Quit" routine. This restores the timer interrupt, for
one thing. Anyway, now you get plain English messages and can still bail
out if you want, but won't lock up your computer anymore if you do!
Also added some obscure functions to Print-Thru that used to work with
the original Atari 40  column printer, the one that plugged right into the
SIO port. I don't know if any software out there sends these commands or
not. Also added the SHAREWARE message at the end of the program.

2.5   Adding user command "A" to adjust timing values. Allows user to
set critical time delays used in the bus data transfers, to try to iron out
differences between different systems. This addition is menu choice "A"
and adds the TIMING menu. This shouldn't be necessary in 99% of
cases, but here it is in case. See the "timing" section or the TECHNICAL
INFO part of this DOC for more info.

2.6  Worked over the PRINT_THRU routine to make it more flexible and
more compatible with the 850 interface. Also moved the default "timings"
value to the front of the program to make it easier to find and change with
DEBUG or NORTON's utilities.

2.7  Changed the PRINT_THRU routine so it will detect a "disk full"
error when printing to a file, alert the user, terminate the PRINT_THRU
process. This need was pointed out in Bob Wooley's AIM review.

2.8  Fixed a bad printer bug caused by rev 2.6 in which lock up of the PC
would occur if you were converting EOL's to CR/LF's and an EOL
occurred at byte 40 of the printer buffer. I also got rid of the space added
after CR/LF because it was causing problems. Also fixed so the ESCAPE
key works the same as 'R' to restore the screen. Most people jab the ESC
key when they get confused.


2.9  Did a little more work on the "disk full" problem so it gets addressed
anytime you are writing to a disk: PRINT_THRU, FILE2PC, or WRITE
DISK FILE.

2.10  More work on Print-thru. Added more LOCATION and ERROR
codes to help in trapping errors.  Also added a time value to the
TIMINGS menu to be used when printing to a real printer. It causes a
wait between records sent to the printer.

2.11  Added a byte count to the sign off message so the user can check if
a virus has changed the program size.

2.12  Added directory function to extract the Atari disk directory from a
disk image file.  Now working for Atari DOS 2 & 2.5 compatible DOSes
only.


3.00  Added "file access" disks.  Now the user can have disks up to 16
megabytes in size.  Increased allowable disk numbers from "1 thru 4" to
"1 thru 8".  Added the color interface screen and color coded key fields
and statuses.  Added fields to show the status of the PRINT_THRU
function.  Added support for "get configuration" and "set configuration"
commands.  Added the "sector #" and "free ram" fields to the status line.
Fixed the status line so it's updated even when not being displayed.  Fixed
a bug which caused return of incorrect status for double density disk
images.  Warns before uninstalling a ramdisk which hasn't been saved.
Formatting now clears the disk image to zeroes so it can be compacted
better.  Killed a small bug on the REMOTE CONTROL program which
may have appended one spurious character onto the command string.
Split source file into 3 parts.

3.01  Corrected some bugs from 3.00;  Added ULTRA SPEED I/O
(SPARTADOS compatible).  I don't have all the difficulties worked out
yet, but it is working.  The bit rates available on the Atari don't exactly
match those available on the PC, so I had to pick a rate where they were
practically the same: 38 KB.  This isn't as fast as the US Doubler can go,
but it IS twice as fast as SIO2PC usually goes.  A few cautions are in
order.  I couldn't fully understand all the stuff SPARTA DOS is doing.  It
goes to high speed, then back to regular, and again to high. I get lost
somewhere in the middle as to what is the signal to go back to high speed.
As a patch, I put in the "J" command, for Jump to Ultra-speed. It actully
toggles between the two speeds. (There's also a new field on the status
line for speed: "N" for normal, "H" for High.) We'll find other
complications as we go along.  For instance, trying to mix high speed stuff
with functions which work in regular speed (PRINT_THRU, REMOTE,
FILE2PC) will probably cause problems. We should probably limit the
high speed stuff to loading, saving, and copying files.  But that's most of
what we do anyway, right? Also did a lot more work on disk
configurations.  I'd especially like any SPARTADOS experts to tell me
how it tells me to go back to high speed. What is the '@' command
SPARTA sends to device $4F?  Also any info on how to get
SPARTADOS to accept ANY size disk image would be useful.

3.02  Fixed a bug which was keeping the DATA out line on too long.

3.03  Added virus check routines for file length and CRC.  Fixed a bug in
FILE2PC.OBJ.

3.04   I did some work on the directory functions. First, a minor fix.  The
separator between a filename and its extension was supposed be a period
(.) for a normal file and a star (*) for a subdirectory. This logic was
reversed until now. Second, I've added SPARTADOS awareness to the
function which extracts directories from Atari disk images.  For the
program to know that the file is a SPARTA image, its name must end in
an 'S'.  I use an 'ATS' extension for SPARTA images and 'ATR' for
others.  A nice feature I added for this function is the ability to
automatically expand subdirectories in addition to the Main directory.  I
don't even have this working for MYDOS yet.  You can view all your
Atari files with a request to see '*.AT?' if you use a naming convention
like mine. OK, SPARTADOS users, are you happy now? I'm also doing
some hardware changes.  I'm now going to a hardware version which is
simpler, but should work better.  It doesn't use Tri-state logic.  Instead, it
uses an open collector type logic to keep from interfering with other bus
devices.  This design should be better capable of not interferring when the
PC is off.  Since there is no Tri-state switching, the RTS line is not used,
and the "Lock Data Line" function has no meaning.  Also, the status of
the command line to the PC is inverted.  This necessitated a change in
software. For the new hardware, the revision number at the top of the
screen ends in a lower case 'i'.  I'm putting this information out in case I
get the wrong version to anyone.  It will ususlly work, but sputter along.
Whichever version you have, just let me know if you want the other one
and I'll send it.  I would send out both versions now, but there's not
enough room on a 360K distribution disk. (Also, ACOMINIT.COM is
not needed with the new hardware.)

3.0  I added many more choices to the standard disk sizes for the "create
disk" option.  The new choices are those which correspond the selections
in the SPARTADOS format menu.  This is to make your choices easier
when using SPARTADOS.  Internally, things still work the same.  Again,
with MYDOS, you shouldn't need to worry about certain prescribed sizes.
I did a lot of tweaking on the "main loop" (the one which monitors the
bus for commands and dispatches the various SIO command functions).  I
think I found one error.  One user (at least) was having major problems
with revision 3.03.

The main event for 3.05 is the addition of what I call "simulated" disks,
described earlier.  I also added a feature to get rid of the character in the
ERR field of the status line when you use the "R" command or just press
ESCAPE. This gets you back to a clean slate.  To be honest, even I don't
know why some of these errors occur, but most are harmless.  For
instance, your Atari DOS may be polling non-existent devices to see
what's there. There's another thing the "R"/ESC command does for you:
It bugs some people that the cursor ends up at the right end of the screen
after some functions are completed.  They think this means the system is
"hung up."  The "restore screen" command will put the cursor  back on
the left, where it belongs.

3.07: I added another translation to the PRINT-THRU function.  Now,
you can also change the ATASCII tab character to a standard ASCII TAB
in the PRINT-THRU process.  A 'T' on the PRINT-THRU status line
shows that you have chosen this option.

3.08:  The main improvement added in rev. 3.08 is the ability to "shell
out" to DOS. This is described in the Technical Notes section. Added
automatic (user's choice) correction of the internal CRC if legitimate
changes caused a false virus warning (The user must verify this.)

3.09:  Fixed a small bug which caused numbers in the filenames of
simulated disks show up as graphics symbols in the Atari directory of the
disk.  It was in the "convert to uppercase" routine: numbers don't need
converting!

3.10:  Made some changes to the "simulated" disk function: First, it no
longer returns an error (just an 'S' in the ERR field) if the Atari tries to
write to the disk.  Second, it now gives the simulated disk a "normal"
status - not "locked" and not "in use."  Why did I do such a crazy thing?
Well, some programs (such as my assembler, AMAC) want to open the
file for write access, even though they don't intend to write to it.  Don't
ask me why.  Opening the file in this way includes writing to the directory
sector.  It could be that others have encountered this problem.  Anyway,
now I can write my source code on the PC, filter it through a utility to
convert it from ASCII to ATASCII, and assemble my program without
ever copying it to an Atari disk or disk image.  Another change is to the
sector number reported by the simulated disk.  It's pretty boring and not
very informative watching all those sector # 100s go by on the status line.
So now, the program now starts with sector 401 and counts up to 700,
then again cycles to 401.  (Note: it's still sending sequential data, it just
reuses the sector number.  DOS isn't smart enough to realize it's seen the
sector number before, and some DOSs might get confused by sector
nunbers > 720.)

3.11 - More changes to simulated disks: now you can install a simulated
BOOT disk, by using /B after the file name on the 'I' menu choice.  I also
did a little human engineering on the virus/CRC warning message.  I want
people to realize that  something's potentially not right.  So now the
warning is in flashing green.  Also, to fix the CRC (after assuring oneself
that there isn't really a virus at fault), the user must type 'OK' instead of
just 'Y'.

3.12  Found a bug in the extract Atari directory function which caused
improper action on SPARTADOS files.  Also added an Escape Key
bailout from that function.

3.13  A user complained that he gets printer timeout errors  when  using
PRINT-THRU, so I experimentally increased some timing values.

3.14 - I found that the speed of "simulated" disk accesses  had  slowed
for unknown reasons.  Turns out I had duplicated a variable name with a
local code label, so a timing value was greatly increased.  Fixed it by
assigning a new label in my source code.

3.15 - Added screen blanking.  Press "B" to blank the screen and ESC to
restore.  Note: didn't add this feature to the Menu.  I want to make it
automatic in the future.

3.16 - Worked on the GET_DIR and GET_DRIVE subroutines, to cure a
problem resulting in an INT 024h hardware error on startup.  It seems
that DOS function 019h (get default drive #) returns the number based on
0 = A, 1 = B, etc.  But function 047h askes for a drive number code
based on 0 = default, 1 = A, etc.  This difference caused drive 2 (C from
function 19) to translate to drive 2, B, for function 047h; and a hardware
error resulted if no disk in drive B.

3.17 - Fixed many inconsistencies and bugs and added enhancements in
response to a letter from Dr. Terry Chamberlain of Cheshire, England.
He sent me a one page letter of praise for SIO2PC plus a 16 page text file
listing bugs and desired improvements.  The changes are briefly:

Lengthened bus timing values.

Major changes to standard disk formats:  What a hassle!  I can't believe
that all these years I thought a 1050 enhanced disk had 1120 sectors (28
sectors/track) and no one else straightened me out!  My main excuse is
that I never had a 1050 drive until I was around the version 3.0 stage of
SIO2PC.  Anyway, I have completely redone my option 6(More)
selections to include all of what he gave me.  I also made choice 3 of the
initial list be 133K instead of 143K to correctly give the 1050 drive
standard size.  Through all of this I found one or two other minor bugs
and fixed them.  I hope this makes formatting easier for SpartaDos users
and users of other DOSes as well.

Fixed a minor irritant:  When you press ESC to abort you input under
Create Disk option 5 (input # of sectors) you instead get a linefeed and a
"/".  This caused me to rewrite my "line input" handler, so now backspace
works as expected in this function and other functions requiring input as
well.  And ESC will now get you out of sub-option C-5.

When using /P to force a file access disk, subsequent requests were also
treated as if /P had been chosen.  Fixed that.  Hope I also fixed some
other glitches in file access disk operation so it will be more robust.

Now when you shell out to DOS, it doesn't default to
C:\COMMAND.COM for its comspec.  It gets the comspec from the
environment string, which should make the DOS SHELL feature usable
for more users.  For instance, if you boot from A: or if you use another
command processor, like 4DOS.

The Extract SpartaDos directory function was messed up!  It didn't get all
files and didn't expand subdirectories.  This was a real shock after all the
work I put in on this feature.  Anyway, now it's fixed.

These fixes and enhancements should make SIO2PC work more smoothly
for everyone.  Thanks to Terry for his careful research.



PROBLEM DIAGNOSIS QUESTIONS

If you have trouble, I would like some information about your system.
(Actually, I'm interested even if you don't have problems. Please send
your comments.)

What kind of Atari? 800? 400? XE? XL? 1200? 600?

What Atari DOS? What type of formatting?

What kind and class of PC? XT? AT? '386? Original PC? Clock Speed?

Has your port been verified functional with other equipment?

What version of PC/MS DOS?

What does the status line at the bottom of the program show?

How long does TESTIME1.EXE take to run? (Should be close to10
seconds.)

Any detailed information from your PC's tech manual about your serial
ports and port addresses in general will be useful.

If you only have problems part of the time, what specific steps lead to the
problem?

Please read the REV_LOG and TECHINFO sections of this for some
more information which may help with problems. Read also any other
.DOC files you find on the disk - there are tidbits of information scattered
through various files which may be of use to you.


POSSIBLE PROBLEMS AND SOLUTIONS

Can't address certain drives

If you are unable to address certain drives,  such as  3, 4, 5, 6, 7, 8 (error
160 results), it may be that your DOS isn't  set up to include these drives.
On Atari DOS 2 and 2.5, you can  find out  by booting in BASIC and
giving a PRINT PEEK (1802)  command. The resulting number is the
sum of the following: 1 for drive  1; 2  for drive 2; 4 for drive 3, and 8 for
drive 4. So if  you  get "3," your DOS is set up for drives 1 and 2 only.
To fix your DOS, you  simply  execute a POKE 1802,15 command.
Then go to  DOS  and execute  the "H" WRITE DOS FILES command.
Finally, turn  off  the computer and reboot.

Another  error that has plagued me from time to time is  this:  I "create" a
ramdisk, then try to write to it without formatting it first.  Remember, if
you create a ramdisk from scratch, you  have to format it. If you load up a
stored ramdisk, you don't have  to format (or create) the ramdisk.
Another  problem which isn't the fault of SIO2PC, comes when  you try
to format a 92K ramdisk with DOS 2.5's normal  command.  You must
use  the "format single" command here.  The  normal  format command
of  DOS 2.5 only works with the 143K ramdisks.  On  some format
related  errors, the Atari will  retry  "forever"  before giving  up and
reporting the error. So you may think  the  system has locked up.

Note that on the 64K ramdisk, the program doesn't report back  to the
Atari  that  the full set of 720  sectors  isn't  available. You'll  get an error
138 on the Atari if you try to put too  much data to this ramdisk. A utility
is needed to mark the unavailable sectors  as "used" on your DOS's
VTOC. If this all sounds  pretty intimidating, you may want to steer clear
of the 64K ramdisk. (As of rev 3.00, the program DOES report the
number of sectors available - if the DOS is smart enough to ask.  But with
some disk image configurations, it may now be MANDATORY to
configure your Atari DOS to recognize the disk.)

Here's a problem I had recently (1993):  I was using SIO2PC, which had
been working fine before, and it started sputtering along and returning
errors (on the Atari) when disk transfers were attempted.  After much
brainstorming and fearing a hardware problem, I found out that the
problem stemmed from "shelling out" to DOS from WINDOWS.
Evidently, WINDOWS keeps "checking up" on DOS programs to the
extent that it can interfere with high speed data transfers.

Noise, especially from Printer:

One user told me that his SIO2PC was susceptible to noise pickup from
power cords, etc. (I have been able to run 75' of unshielded cable near
power cords, over air conditioning units, etc, without problems, so you
never know.) Anyway, he said he wrapped the box in foil and fixed it. I
don't know if I'd go that far, but if you have intermittent problems, you
might look at the cable routing. Yet another potential pitfall: You will
usually remember when you have a real disk installed, you must not have
an SIO2PC ramdisk of the same number, since a collision will occur. But
sometimes you (I) will boot up a DOS which automatically installs a
ramdisk handler on the Atari, forgetting that there is an SIO2PC ramdisk
of the same number. When I try to access this disk #, I get strange results
not immediately identifiable as to the cause. So, if you use Atari ramdisks,
watch out for this.

Along this same line: I just got a letter from a user who was having
trouble with the PRINT_THRU function. It would stop printing at
unpredictable places. Then he noticed that the Atari was plugged into a
surge suppressor, but the PC and printer weren't. When he plugged those
items into a surge suppressor, the problem was fixed. So this is a major
Ah-Ha! for anyone having random problems in this area. Printers generate
a lot of electrical noise. I never have this problem on my system, but no
wonder: My Atari and PC aren't on the same desk, they are powered from
separate wall receptacles, and each has its own surge/noise suppressor.
Let me suggest a couple of other things: Make sure your SIO2PC cable
and your printer cable are kept separate. If your printer and serial cables
have thumbscrews, tighten them up. I noticed this made a big
improvement on the amount of noise my computer outputs to my ham
radio.

If you can't get rid of the noise, here's another solution, but not quite as
clean: Set up SIO2PC to capture the Atari's printout to a file. Then leave
SIO2PC and use the PC DOS COPY command to copy the file to the
printer (PRN). Use the MS DOS "binary switch" option, or your printer
control codes won't make it thru the copy process.  Here's another reason
to use the "binary switch" option, discovered recently.  A guy was using
this method and it worked fine except that the process would stop short
before the data was completely transferred to the printer.  When MSDOS
is copying files and isn't in the binary mode (/B switch), it looks for the
1A hex character as an end of file marker.  If a 1A byte is in your printer
data, the transfer will stop at that point unless you use the binary switch.



Lock Data Line

Rev. 2.3 added a switch (function "K") to allow locking the data out line
into the enabled state. This is for a user or two who had a specific
problem which occurred when the data line went to the inactive state
automatically. You should leave this switch in the Auto state. Otherwise,
when you try to address non-SIO2PC devices, interference will result.
However, if you note that when you address an SIO2PC drive and
experience hesitation, sputtering, etc., try locking the data line on and see
if it helps. (I now believe the TIMINGS MENU modification is the real
cure for this type problem.)

Copy protection problems

Some people have told me that some copy protected programs which
have been "broken" will run from a real drive but not from SIO2PC.
Recently, one guy told me of a solution: He uses the TIMINGS menu of
SIO2PC to slow down SIO2PC's I/O rate so it looks like a real drive.
Appapently, some protected programs time the "sector get" and "sector
put" processes to make sure they aren't running out of a ram drive
(indicating that the protection has been broken). Since SIO2PC is a small
program, one could have customized versions which are slowed down just
for use on these problem programs. (Elsewhere in this DOC is info on
how to permanently alter SIO2PC's timings.)

Interference from real drive

In my operating instructions, I tell you to turn off your real drive #1 and
then boot from the SIO2PC disk #1. I haven't heard any complaints about
this, but I recently borrowed a 1050 drive, which, when I turned it off,
interfered with the serial bus and I couldn't read the SIO2PC drive. The
solution was to turn the front lever on the 1050 to the EJECT position but
leave the 1050 on. Apparently this told the 1050 not to answer the call,
which then went through to SIO2PC OK.

Extract Directory Note

Note that the Extract Atari Directory function can't work on disk images
currently in use as "file access" disks on the system.  This is because
SIO2PC already has these files open for read/write and can't open them
again to extract the directory.

Status Line Note

You may notice that under certain conditions your status line is not being
updated.  This occurs when you have PRINT_THRU enabled with the
screen selected as the output device.  To keep the status field characters
from messing up your screen print, the status line update is inhibited until
you turn off PRINT_THRU.

USER'S QUESTIONS

1) Does the program reformat my PC's hard disk?

No! Your Atari disk images are stored on your PC as ordinary PC files.

2) Could I use the hardware part of the SIO2PC system as a general
purpose RS-232 interface? Like, to connect my Atari to a modem?

Hmmm... This is a good question, and the answer is sort of, "yes and no."
Electrically, yes you have a true RS-232 connection coming out of the
interface. However, note the following:

RS-232 includes several handshaking lines in both directions. But, most
communications setups only use a few, and optionally can be told by
software to disregard those they do have. I've seen computer to computer
PC data links that had just Data in, Data out, and ground (via RS232
serial port). My system has one handshaking line from the Atari to the
PC, the COMMAND line which goes to RI on the PC. You can often
"dummy up" inputs to fool one end of a link into thinking the other end is
saying, "ready." A null modem cable is usually made up this way.

Bit rate (BAUD) and software on the Atari end: On the Atari, the SIO
subsystem of the OS always works at a fixed rate: 19.2 Kilo- baud, except
for the cassette: 300 baud. Also, it uses a strict protocol to send data:
command frame, acknowledge, data frame, acknowledge, complete. But
if you want to write your own software (or you have some already
written), you can directly program the Atari's POKEY chip (UART) to
any baud you want, and you can directly put data into its transmitter for
sending, and can directly read incoming data from the receiver. (My notes
under ATARICOM.DOC talk about how I did this once.) When you do
this, you are completely bypassing SIO and running the whole show
yourself. You can also control the handshaking lines yourself. To get into
something this serious, you need the Atari Technical User's Notes. It's fun
to learn, but takes some time.

Actually, since writing the above response, I HAVE written a specialized
terminal program for my Atari using SIO (no 850 interface) configured
for 9600 baud and connected to a Packet Radio terminal controller which
uses the RS-232 standard.

3) How come SIO2PC is a dead end - no extra port for adding another
device?

I'm finding out this bothers some people. I figured, you could alway make
this the last device in your chain. But I guess other manufacturers figured
the same. It would be vastly more complicated for  me to build a box with
a receptacle or two for SIO in it. They generally come as PC board
mounted connectors, not as "in line" types like the plug I do use. So my
board would be much bigger, I would be hand cutting rectangular cutouts
in the box, etc.  However, someone had a suggestion, if you are building
your own: He said the "newer" cassette recorder (the 1010?) had two
SIO2PC jacks in it. You could get a surplus 1010 junker for a few bucks,
gut it except for the connectors, and build your SIO2PC in this box.
Alternately, you could just buy a couple of the jacks from your friendly
Atari parts supplier and design them onto your board.

Here's another idea:  build the interface into your Atari. Mount a DB-9 in
the Atari's case. (I've done this.)  Then, your SIO port would still be free,
and you just use a standard serial cable to connect your Atari to any PC.


4)  Will SIO2PC run on an Atari ST running PC ditto?

From what I've heard so far, no. SIO2PC does a lot of direct to the chip
I/O, bypassing both MS-DOS and the PC's built in BIOS routines. I
suspect that PC ditto doesn't emulate the PC down to this level. However,
if there are any ST experts out there who want to work with me on it, I
think we could modify the program to make it work. I configure the serial
chip (UART) directly because the PC BIOS doesn't have 19.2 kilobaud as
an option, although the chip will do it. I input and output data from/to the
UART directly for speed. I have also reprogramed the PC's timer chip
and have a timer driven interrupt running. I think all this could be worked
out if we had the right info. How about it, ST users?

5) Will you give out your source code for SIO2PC?

I don't routinely give it out. But if you would like to have the source code
just to see how it's done, or to make some modifications, or even to
"borrow" the basic I/O routines for use in your own non-commercial
programs - write and let me know. SIO2PC is written entirely in assembly
language for the MICROSOFT QUICK ASSEMBLER.  I also have a
version which will assemble under A86, the excellent shareware
assembler.

6) How about a default path?

One person asked to be able to have a default path so he wouldn't have to
tell SIO2PC where to find his disk images.  I usually run SIO2PC out of
the directory where my files are stored, so I don't need to specify a path.
However, I just recently realized that DOS has a command built
(SUBST) in which allows you to specify a virtual "drive" letter for any
path.  For instance, from the DOS prompt, type SUBST E:
C:\ATARI\DISKS.  After this, you can substitute drive E: for the full
pathname, even from within SIO2PC.  A pretty convenient feature.

7) Direct access to hard disks / HUGE Atari disk images.

I am getting a lot of requests from people wanting to have HUGE Atari
disk images and direct access to the PC's disks.  I'm opposed to using
direct sector writes on PC disks. The possibility of inadvertent destruction
of PC files is too great and I'm afraid of the risk.  However, I'm thinking
of having random sized disk images stored as PC files which would not be
moved into PC ram.  I would have to use MS DOS's file pointing features
to read in the correct "sector" directly from the file.  The DOS overhead
would slow things down a bit, but I have an idea that it wouldn't be too
bad. **** DONE ***

WHO'S NICK KENNEDY?

I'm an electrical engineer, but I don't work with computers professionally.
That part is a hobby. I got the Atari 800 in 1982, mostly so I could play
Asteriods.

Data communications interests me. I have written a Morse code program
to interface the Atari with my Ham Radio station. Later, as a sort of
evolutionary forerunner to SIO2PC, I wrote programs linking my two
Atari 800's together, first via their serial (SIO) ports, and later via their
joystick ports. The Atari equipped with a disk drive would send files to
the one without.

I thoroughly enjoy programming in assembly language, and may attempt
"C", if threatened at gunpoint.

To me, the hardest part of programming is finding a worthy cause. There
are so many programs out there, commercial, free, and shareware - all
good, that it's hard to find a niche that hasn't been filled. I think SIO2PC
fits the bill.

As I've said before, I'm very interested in your comments, suggestions,
questions, praise and condemnations. So, if you built it yourself and have
a comment, let me hear from you, even if you weren't moved enough to
pay a shareware fee. I won't harangue you about it.

Nick Kennedy


OTHER PROGRAMS

I thought I'd tell about other programs I've written, on the off chance
someone may find one of them useful.  Everything I've done involves
interfacing a computer to another computer or to other external devices.
All of my programs address some oddball specific need I had at one time
or other.  These programs fulfill a function, but some of them lack polish:

PINEWOOD.EXE - Written to time external events (in my case,
pinewood derby cars) to millisecond accuracy.  You hook a START
switch to one serial input line and STOP switches to two others. (Only
one serial port is required.)  I used phototransistors for the stop switches.
The program starts timing when the START switch changes state, gives
the time that each car (event) activates its STOP switch, and proclaims the
winner!

TIMER.COM - A variation on the above.  This timer just monitors one
line.  It starts timing when the line changes state and stops when it returns
to its resting state.  I used it to time a "one shot" device (a 555) to make
sure it was giving exactly the 50 milliseconds I needed.  This program
would probably be called an interval timer.

PACKET.OBJ - A packet radio controller for the Atari 800.  This version
is specifically set up to send control strings to an MFJ-1278 controller.
Note: this is a ham radio thing.  Essentially, this is a terminal program
similar to what one uses with a modem.  It doesn't have advanced features
such as file capture, etc.

EPROM.COM - Interested in burning your own EPROMs?  Make your
own Atari cartridges?  I built Steve Ciarcia's Serial EPROM Programmer
from the Circuit Cellar, volume VI book.  The companion BASIC
controller program left much to be desired, so I wrote a faster and more
flexible one in assembler.

FREQ.COM & SYNTH.OBJ - Another ham/experimenter thing.  This
program - which I have written for the PC, the Atari 800, and for a 6502
single board computer - is a controller for a Direct Digital Frequency
Synthesizer.  The synthesizer works from 0 to about 7 MHz, and has 1
hertz resolution.  The controller gives the many fancy features of modern
ham transceivers:  split transmit/receive frequencies, memories, memory
scan, band scan, etc.

In the "EXTRAS" directory of the distribution disk, I've already told you
about my programs linking two Atari's, and about my ham program
KEYER.OBJ - the morse code keyer program which took almost as much
programming time as SIO2PC.

If any of these things meets a need, let me know.
  NOTE: SAVE THIS FILE AS PLAIN TEXT /W LINE BREAKS ... *.TXT, WITH MARGIN
AT 4 7/8.